Microsoft ADFS and Tyler Identity

Tyler Technologies has introduced an exciting new product called Tyler Identity (TID), which offers additional flexibility in authentication options for the various products in the Tyler suite. Utilizing your organization's existing infrastructure, TID further secures user logins by using heightened encryption technologies when your workforce logs into the system.

In some instances, an organization may have several domains in their environment in which users will need to log in from. In a typical NWERP environment, one domain is used, and all users generally exist under this domain. In more complex environments, however, users may exist in several domains that are part of the same organization, and thus need to be handled accordingly.

Microsoft has developed technology that pulls these different scenarios together and, with the integration of TID, users in a multi-domain scenario may still access NWERP.

Active Directory Federation Services is a mechanism to provide access to users homed in your Active Directory forest to Web services located in other Active Directory forests. E.g. Partner organizations, Office 365 etc.

ADFS provides authorization, authentication and Single Sign-On (SSO) functionality to web applications and services located virtually anywhere, including perimeter networks, partner organizations & cloud.

Active Directory trust works on Kerberos V5 or NTLM protocol and it provides access to users on resources located in different domain or forest. The Kerberos or NTLM token is validated for the SPN (Service Principle Name) before providing access.

ADFS works on protocol called SAML (Security Assertion Markup Language). The Web application configured for ADFS looks for ADFS cookie, redirects the URL to user’s ADFS server for user validation and ADFS server generates token/claim upon successful user login, appends it to the URL and sends it back to the Web Application requested for it. The Web application now sees ADFS cookie and grants access to the Web application.

The cookie is valid for default 10 hours and can be customized.

ADFS uses Secure Socket Layer (SSL) between in the entire path of user validation and it completely secure and recommended.

The user credentials are known only to local ADFS instance of Active Directory server and only the authorized token is passed along the URL. Because the entire session is SSL based and tokens are encrypted, entire ADFS flow is secured.

The installation of Microsoft ADFS is the sole responsibility of the customer or by a third-party organization as hired by the customer.

Note: The user account used to install ADFS services must be part of a local or Domain administrator group as the process touches many aspects of the Operating System. This will need to be performed on both the Domain level AD server as well as the NWERP application server.

The following link to instructions are provided by Microsoft to install the ADFS service and are subject to change at their discretion:

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/install-the-ad-fs-role-service

  • ADFS Functional Levels Supported: 2012, 2012R2, 2016 (2016 preferred).

  • Integration Type: WSFed w/o Account Linking.

    ADFS 2012,2012R2 & 2016 uses WS-Fed integration.

  • 2016 ADFS works with AD DS 2008R2 and up so the client would not have to upgrade the DCs.
  • ADGroup called “tyleradmins” (or something to your liking) will be utilized for administration. All appropriate administrative accounts will need to be added to this group, and credentials provided.
  • Complete list of AD users will be needed, and each user in AD must have a valid email address.
  • Profiles must be created, such as “ADFS” within the setup.

  • Support to be enabled for WS-Federation passive protocol for TID URLs.

    Ex: https://<tidserver>.<yourdomain>.com/IDPTokenServertidCore OR https://<tidserver>.<yourdomain>.com/prod/tylerid/authtokenserver

  • Relying Party Trust must be identified and supplied to Tyler. This is manually entered during the setup process.

    Ex: urn:tylerIdentity

  • Metadata address to be supplied to Tyler.

    Ex: https://adfs.<client>.org/federationmetadata/2007-06/federationmetadata.xml

  • Claims Transformation to be updated and supplied to Tyler.

    Ex: